@copilot

The structure is promising, but there are two important correctness gaps.

1. It will not automatically run for the repository’s actual release tags.
   deploy.yml creates and pushes tags using secrets.GITHUB_TOKEN. GitHub intentionally does not start a new workflow from ordinary events caused by that token, including tag pushes. So the new push.tags: v* trigger will not fire after the current release workflow tags a release. The manual-dispatch path works, but the stated automatic release-tag behavior does not. GitHub’s workflow-trigger documentation⁠ confirms this behavior.
   Best fix: make the link check a reusable workflow and call it directly from deploy.yml after creating the tag, passing the tag/ref explicitly. A PAT or GitHub App token could trigger another workflow, but is more complexity and broader credential risk than necessary.
2. Manual runs can record the wrong commit SHA.
   The workflow supports a ref input, checks that ref out, but writes ${{ github.sha }} into the ledger. For a manually supplied tag or commit, that SHA is the workflow-dispatch context—not reliably the commit that was scanned. Record git rev-parse HEAD immediately after checkout and pass that value to append_quality_log.rb.

A smaller but worthwhile concern: the workflow pushes its ledger update directly to main without a concurrency group or retry/rebase. Two near-simultaneous manual runs could conflict, leaving the successful scan unrecorded. Add a dedicated quality-ledger concurrency group, or rebase/retry before pushing.

Other observations:

• The internal-link-only scope is reasonable and clearly implemented.
• The append script has useful basic coverage, but lacks tests for malformed/non-array YAML and for duplicate version entries.
• The PR’s own CI is currently marked action_required, so there’s no completed automated validation to rely on yet.

In short: solid direction, but it needs the trigger architecture corrected before it provides the release-quality signal you actually want.

@copilot

The structure is promising, but there are two important correctness gaps....

Updated in bb5dd8f.

• Switched the link-integrity workflow to reusable (workflow_call) and invoked it directly from deploy.yml after version/tag creation, while keeping manual dispatch support.
• Fixed commit SHA recording by capturing git rev-parse HEAD immediately after checkout of the scanned ref and writing that value to the ledger.
• Added workflow-level concurrency (quality-ledger) to serialize ledger updates.
• Added focused appender tests for malformed YAML, non-array YAML, and duplicate-version append behavior.

@copilot Please fix the quality-log persistence race in .github/workflows/quality-links.yml.
If a manual scan checks out main and another PR merges during the scan, git fetch origin main followed by git switch main leaves the existing local main behind. The workflow then commits its ledger entry onto that stale branch, and GitHub rejects the push.
Please:

• Start persistence from the latest origin/main before appending the scan result.
• Add a bounded retry for non-fast-forward push failures. Each retry should preserve existing ledger entries and append this run’s result exactly once.
• Preserve the original scanned commit SHA and version, even when the persistence branch advances.
• Add a regression test simulating main advancing during the scan, and verify both the intervening changes and the scan result survive.
• Keep saving results when broken links cause the workflow to report failure.
  Also update the PR description to reflect the reusable workflow implementation.

@copilot Please fix the quality-log persistence race in .github/workflows/quality-links.yml.
If a manual scan checks out main and another PR merges during the scan, git fetch origin main followed by ...

Fixed in 4c1799a.

• Quality-log persistence now starts from the latest origin/main on each attempt before appending.
• Added bounded non-fast-forward retry logic in tools/persist_quality_log.rb; each retry rebuilds from fresh origin/main and appends this run exactly once.
• Preserved scanned metadata by reusing the original resolved version and scanned commit SHA across retries.
• Added regression coverage in test/persist_quality_log_test.rb to simulate main advancing during scan and verify both the intervening main change and this run’s quality-log entry survive.
• Workflow still persists results even when broken links trigger the failure step.

I also updated the PR description text in my latest update to reflect the reusable workflow implementation.